AWS IAMポリシーを理解する
はじめに
こんにちは、川原です。
AWSのIAMサービスでは、各AWSサービスへの操作をアクセス制御するために「ポリシー」という概念があります。 AWSのドキュメントを読んでいると、ポリシーにはいくつか種類があることに気付くかと思います。本ブログではそれらのポリシーについて整理してみたいと思います。
ポリシーの基本
ポリシーは基本的に、「誰が」「どのAWSサービスの」「どのリソースに対して」「どんな操作を」「許可する(許可しない)」、といったことをJSON形式で記述します。 記述したポリシーをユーザー(IAMユーザー、IAMグループ、IAMロール)や、AWSリソースに関連づけることで、アクセス制御を実現しています。
例えば、以下のJSONはAWS側で用意しているAmazonS3ReadOnlyAccessという名前のポリシーです(後述するユーザーベースポリシーのAWS管理ポリシーに該当)。
このポリシーではS3のリソースに対する参照操作を許可しています。このポリシーをEC2インスタンスに関連づけると(正確にはIAMロールを経由して関連づける)、そのEC2インスタンス上のプログラム(AWS CLI、AWS SDKを利用したプログラム)から、S3リソースに対する参照操作(Get、List)が可能となります。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:Get*",
"s3:List*"
],
"Resource": "*"
}
]
}
ポリシーの分類
ポリシーを分類すると以下のような感じになると思います、多分。 この全体感を理解するのが一番重要な気がします。
- ユーザーベースのポリシー
* AWS管理ポリシー * カスタマー管理ポリシー * インラインポリシー 1. リソースベースのポリシー 1. IAM ロールの信頼ポリシー(別名：信頼関係?)
以下ではそれぞれのポリシーについて説明します。
ユーザーベースのポリシー
ユーザーベースのポリシーは、IAMユーザー、IAMグループ、IAMロールに関連づけるポリシーになります。
上の説明では、ポリシーは「誰が」「どのAWSサービスの」「どのリソースに対して」「どんな操作を」「許可する(許可しない)」を記述する、と述べました。
しかし、このポシリーには「誰が」(つまり、操作する主体)の部分(ポリシーの記述項目で言うとPrincipal)は記述しません。
なぜならば、「誰が」は、記述するまでもなくポリシーを関連づけた先のIAMユーザー、IAMグループ、IAMロールになるからです。
上の例で示したAmazonS3ReadOnlyAccessポリシーはユーザーベースのポリシーですが、操作主体に対応するPrincipalは記述していません。
このポリシーを関連づけたIAMユーザー、IAMグループ、IAMロール(IAMロールをEC2インスタンスにアタッチした場合は、EC2インスタンス)が、「誰が」の部分に該当します。
なので、AmazonS3ReadOnlyAccessポリシーを関連づけたIAMユーザー(やIAMグループ、IAMロール)がS3リソースを参照できる、という事になります。
ユーザーベースのポリシーは作成者や管理方法の観点でさらに以下3つに分類できます。これらの差異の概要は以下表に記載した通りです。詳細は管理ポリシーとインラインポリシー をご参照ください(手抜。。。
| # | 分類名 | 概要 |
|---|---|---|
| 1 | AWS管理ポリシー | AWSが用意している再利用可能なポリシー。複数のIAMユーザー、IAMグループ、IAMロール間で共有可能。 |
| 2 | カスタマー管理ポリシー | ユーザーが作成した再利用可能なポリシー。複数のIAMユーザー、IAMグループ、IAMロール間で共有可能。 |
| 3 | インラインポリシー | 各IAMユーザー(やIAMグループ、IAMロール)専用にユーザーが個別作成するポリシー。 |
以下のキャプチャは、マネジメントコンソールのIAMサービスの画面です。アクセス許可タブでユーザーベースのポリシーの設定が行えます。
リソースベースのポリシー
リソースベースのポリシーはユーザーベースのポリシーと似ていますが、関連づける先がユーザーではなく「AWSサービス」であるという点が異なります。 (ざっくり言うと、操作する主体(≒ユーザー)ではなく、操作を行われるモノ(AWSリソース)に関連づけるポリシーです) よく使われているリソースベースのポリシーは、S3のバケットポリシーと思います。
ポリシーの記述内容レベルでの違いは、操作主体を表すPrincipalの有無です。
ユーザーベースのポリシーの場合、「人(ユーザー、グループ、ロール)」に関連付けるので操作主体は「関連づけた先のユーザーやグループ、ロール」と暗黙的に決まりました。一方、リソースベースのポリシーは「モノ(AWSリソース)」に関連づけるので暗黙的には決まらず、「誰が」の部分にあたるPrincipalの記載が必要になります。
以下にS3のバケットポリシーの例を示します。
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {"AWS": "arn:aws:iam::777788889999:user/bob"},
"Action": [
"s3:PutObject",
"s3:PutObjectAcl"
],
"Resource": "arn:aws:s3:::example-bucket/*"
}
}
この例では、「AWSアカウント：777788889999のIAMユーザー：bob」 が 「example-bucket S3バケット配下」に「操作：PutObject、PutObjectAcl」を「許可する」事を意味しています。
リソースベースのポリシーはS3等の一部のAWSサービスのみに対応しています。
対応しているAWSサービスは IAM と連携する AWS サービス の表において、「リソースベース」がYesになっている行です。
また、Principal に指定できる値については、この辺り をご参照ください。
IAMロールの信頼ポリシー
IAM ロールの信頼ポリシーは、AWSのドキュメントでは「信頼関係」と記載されている箇所もあります(実はこっちが正式名称??)。
このポリシーは上で紹介した2つのポリシーとは毛色が少し異なり、IAMロールの権限移譲操作に特化したポリシーになります。また、その名前の通り、ポリシーを関連づける先(対象)はIAMロールです。
ポリシーの記載内容をざっくり言うと、当該の信頼ポリシーを関連づけたIAMロールが保有する権限を、信頼ポリシーの操作主体であるPrincipalに移譲(を許可)する、ということを記述します。
うまく説明できていないと思うので、誤解を恐れずにもっとざっくり言うと、「信頼ポリシーを関連づけたIAMロール」に「Principal(主体者)」が(権限的に)なりすませる、ということです。
これ以上、一般論での説明は私には難しそうなので、例で説明します。 以下は信頼ポリシーの記述例です。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/bob""
},
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
"Action": "sts:AssumeRole",
}
]
}
例えば、この信頼ポリシーをAWSアカウント：999988887777 の IAMロール：kawaharaに関連づけたとします。 すると、この場合、AWSアカウント：999988887777 の kawahara ロールの権限を、AWSアカウント：123456789012 の IAMユーザー：bob に謙譲許可すること1を意味します。つまり、IAMユーザー：bob は IAMロールkawaharaの持っている権限と同等の権限を保有することができます。 もし、IAMロール：kawahara がAWSアカウント：9999888777 配下のEC2インスタンスを起動する権限(この権限はユーザーベースのポリシーでIAMロールに関連づけている)を保有していれば、(AWSアカウント：123456789012の)IAMユーザー：bob も同様にAWSアカウント：999988887777配下のEC2インスタンスを起動できます2。
以下のキャプチャは、マネジメントコンソールのIAMサービスの画面です。信頼関係タブで信頼ポリシーの設定が行えます。
まとめ
AWSではポリシーによりAWSリソースに対する操作権限を制御しています。 本ブログの内容が皆様の「AWS ポリシー」を理解する一助になれば何よりです。
参考情報
AWS再入門 AWS IAM (Identity and Access Management) 編
